Randomness in Demos

By Seven

Recently I was once again trying to explain the difference between a demo and a movie to a friend of mine, who had never seen a demo before. I had shown The Popular Demo by Farbrausch, with the mirrorball-people dancing around, and I explained how the 3D artist had created the 3D model and had animated it, but that the reflections of the lights on it for eample were calculated in realtime. I had emphasized that it was much harder to create something in realtime, so she asked me what exactly the advantages were of a realtime demo over a moviee. I had to think for a while and could come up only with the much smaller filesize for a given resolution and framerate, but that didn't seem to really capture the essence of a demo. Then she wanted to know if it looked always the same every time the computer calculated it, and then it hit me: even though The Popular Demo and most other demos always look the same, one of the largest advantages of a demo is that it can be randomized!

Randomness in demos has been done before: if I remember correctly 303/Acme has some parts with anti-aliased lines and circles that were randomized, the paper planes in Paper also flew different every time you watched it, and Super Luxus Lumen Pakketti/MFX features effects with a random timing and order. Especially that last demo was one I've rewatched a lot, also because the effects fitted the hypnotizing soundtrack very well. More recently, Tom Thumb/Tpolm was a nice example of a completely randomized production, you can in fact download the sources of it at www.bluespoon.com/?r=tomthumb

A clear advantage of using randomized effects is that a production doesn't get boring as quickly, the rewatchability is much higher, so to say. So why don't we see them more often? I remember hoping when Super Luxus came out that more demos would follow the example, but they're still few and far between. I can only think of 2 reasons why coders want to keep their whole code deterministic:

1) Being in control:

Most demos are shown for the first time on a big screen, and of course you want to know exactly what the audience will see. You don't want to run the risk that due to a coincidence, your effects will look freaky or less than optimal.

Here I think the solution is easy: all random generators need a seed value from which they start generating random numbers. If you give them the same number twice, the sequence of numbers they generate will be twice the same. So if you allow the user to enter the random seed, maybe as a command-line parameter or in a startup dialog, the demo will become deterministic again.

For the compo, you just have to specify the seed value which you think gives the best results. And if you show the used seed number after the demo, fans of your production will be able to start arguing whether they like seed 39683903 better than seed 10825687 :)

2) Too much effort:

This is a much harder problem: for every effect that uses a random parameter, you have to choose limits to the randomness for which the demo still looks good. For example, in a starfield with stars moving at random speeds, you must make sure a star never stands competely still, nor that it zips by so fast you can't see it. So this takes a certain amount of extra work to find the balance between looking different every time, and looking good every time.

But even with minimal efforts, you can make your effects a little bit non-deterministic. Here are some examples:

Easy: just give some variables (speed, position, direction) a random start value.

- The speed and positions of particles in effects such as fountains, waterfalls, starfields, etc.

- In 3D-object shows with rotating objects: the direction in which an object turns around, and the movement of the light sources.

- Waving flags, or waves on water can vary the starting position of the effect.

Medium work: This will need some additional code or extra work to pull of:

- General movement of swarms of objects, like the planes in "Paper". The movement of the individual objects can have a random element, while the swarm still moves as a whole.

- Changing colors: this could be tricky, unless you aim for "the dutch colorscheme". Maybe the artist can make several palettes of colors that match together, and the code can pick a random palette at runtime.

Hard: This will need advanced code and/or a lot of manual work:

- Varying non-random camera paths. This would require you to define two or more camera paths for every scene, and pick one at random. This doubles or triples the work of moving the camera, but the result increases exponentially: If you have 5 scenes with 3 possible camera flights in each, your demo can be viewed in 3^5 = 243 different ways!

Writing these examples, I've noticed the most noticeable effects take the most work: one particle fountain looks pretty much like any other particle fountain, but effects that change color everytime will probably draw much more attention. This may seem discouraging, but to look on the bright side: your efforts will pay off :)

Anyway, I hope this little article has given you some ideas to put in your next production. Without a doubt, it will vastly increase the popularity of your demo, catapulting it to the top of the charts, and making you rich and famous beyond belief.

It will also make it much easier for me to explain the difference between a demo and a movie ;)

Seven